As mentioned in #3662 my compiler seems to autovectorize already. I see -O2 is set when I compile. -O3 includes -ftree-vectorize. Have you looked into setting -O3 as an alternative as well?
How can we autobuild with debug symbols? It would be interesting to know if some runners already automagically handle things like my compiler does.

I benchmarked this change on Linux to help move it forward. Summary: the claim in the PR description is correct — with the current -O2 build flags, g++ vectorizes none of the mixing loops in CServer::MixEncodeTransmitData, and this one-line flag fixes that, making the mix loops 2.2–3.8× faster. It also answers @dingodoppelt's -O3 question: -O3 produces essentially identical mixing performance, so -ftree-vectorize alone gets all of the benefit with a much smaller change.

Setup: g++ 13.3.0 (Ubuntu 24.04, x86-64), current main (6b7a0ad), compiled with the exact flags qmake generates (-pipe -O2 -std=gnu++11 -fPIC + project defines/includes), comparing three variants: stock -O2, -O2 -ftree-vectorize (this PR), and -O3.

1. Compiler vectorization reports on the real server.cpp

-fopt-info-vec-optimized, filtered to MixEncodeTransmitData:

So on GCC 13 nothing in the mixing path vectorizes today, and the PR's flag reaches exactly the same set of loops as -O3. (The delay-pan loops don't vectorize under any variant due to the wrap-around conditionals — pre-existing, unchanged.)

2. Microbenchmark of the mixing loops

Loop bodies lifted verbatim from MixEncodeTransmitData (CVector is std::vector, runtime trip count, same access pattern). Each measurement is one full target-channel frame: buffer reset + mix of N clients + Float2Short conversion; best of 30 runs × 20 000 reps. Times in ns per target-channel frame:

Whole-server impact scales with N² (each of N clients gets its own N-way mix). Example: 50 mono clients at the 128-sample frame size = 50 × 7.9 µs = ~394 µs of mixing per 2.67 ms frame period (≈15% of a core) at -O2, dropping to ~123 µs (≈4.6%) with this PR. Stereo: ≈27% → ≈10%.

3. Safety notes

• These loops vectorize over the sample index; each output sample keeps its exact scalar operation order (no FP reassociation — -ftree-vectorize does not imply -ffast-math), so output is bit-identical, consistent with the "safe to default-enable" assessment.
• The full autobuild matrix on this PR is green, including both Windows builds — MSVC ignores the unknown -ftree-vectorize with a warning, so the flag is inert (not harmful) there. If the warning noise bothers anyone it could be scoped to gcc/clang mkspecs, but it's not a correctness issue.
• @dingodoppelt: on g++ 13, plain -O2 definitely does not enable loop vectorization (-ftree-vectorize is only implied from -O3 up) — if your local builds vectorize at -O2, something else in your flags is adding it. And per the table above, -O3 buys nothing further for this code, so the PR's minimal flag seems like the right call.

Benchmark source available on request.

🤖 Generated with Claude Code

MSVC ignores the unknown -ftree-vectorize with a warning

I think it would be worth putting a guard in the Jamulus.pro, in that case, with a comment saying it's only in GCC.

Additionally, it might be worth investigating what the equivalent in the MSVC builds looks like - in terms of performance now and potential for optimisation. This step isn't a blocker, though.

I've added this to 4.0.0 as it's a small change with potentially wide-scale benefit right now.